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PACKET FORWARD I NG EQUIPMENT 



BACKGROUND OF THE INVENTION 



(1) Field of the 



I n vent ion 
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The present 



invention relates to a multicast 



network in which a source server of a multicast packet 
is specified and, more particularly, to a technique 
for connecting a client node which does not have a 
function of designating a source server of a multicast 

10 packet to a multicast network. 

(2) Description of the Related Art 

Multicast is a technique of transmitting packets 
simultaneously to a plurality of destinations on the 
Internet. The multicast enables distribution of a 

15 large amount of information to a plurality of 
destinations with a smaller amount of packets as 
compared with the case of transmitting packets- to 
respective destinations a plurality of times. 
Consequently, the multicast is particularly suitable 

20 for real-time multimedia communication requiring 
heavy traffic typified by streaming and a video 
conf er ence . 



much in today's world. One of the main reasons is 
25 complexity of multicast routing control. Although 



However , 



a multicast network is. not spread so 
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multicast routing protocols such as DVMRP (Distance 
Vector Multicast Routing Protocol: RFC 1075) and 
PIM-DM (Protocol Independent Multicast- Dense Mode: 
draf t-iet f -pim-dm-new-v2 -0 1 . txt) are simple, 
5 multicast traffic flows also into segments which are 
the units constructing a network and do not need 
multicast traffic, so that the protocols have a 
drawback of low efficiency in a network utilization. 

In operation of a multicast network, PIM-SM 

10 (Protocol Independent Mu 1 t i c a s t- Spa r s e Mode: RFC 
2362) which overcomes the drawback is usually used. 
According to PIM-SM, multicast traffic is allowed to 
flow only to the minimum segments. However, since 
overhead for calculation of a multicast transmission 

15 tree is large, PIM-SM has problems such that the 
protocol is complicated. Therefore, it is difficult 
to carry out the protocol, and a load on a router is 
heavy (Asaeda, "New Communication Architecture by 
Source Specific Multicast'', Information Processing, 

20 March, 2002, Vol. 43, No. 3, pp. 260-265). 

One of promising techniques proposed to address 
the complexity is s o u r c e - s p e c i f i c multicast. In 
conventional N-to-N multicast communication, a 
multicast receiving terminal transmits a request to 

25 join a multicast group. In the s o u r c e - s pe c i f i c 
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multicast, when a multicast receiving terminal sends 
a request to join a multicast group, it is necessary 
to designate the source address of a multicast packet. 
The designation of the multicast source address by 
5 the multicast packet receiving terminal aims at 
limiting a packet forwarding process to one-to-N 
multicast communication to make the multicast routing 
control simpler (draft-ietf-ssm-overview-OO.txt) . 
Considering that many of cases of applying multicast 
10 are streaming from a small number of servers, even 
if the packet forwarding process is limited to one-to-N 
communication, the user needs for multicast can be 
satisfied. 

A principal difference between source-specific 
15 multicast routing control and conventional general 
multicast routing control is that, in the source- 
specific multicast routing control, when an end user 
terminal joins a multicast group, the address of a 
source server of a multicast packet have to be 
20 designated together with the address of the multicast 
group. To j oin the source-specific multicast network, 
the end user terminal has to support a multicast group 
management protocol adapted to the s o u r c e - s pe c i f i c 
type, for example, IGMPv3 (Internet Group Management 
25 Protocol Version 3) in IPv4 or ML D v 2 (Multicast 
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Listener Discovery Version 2) in IPv6. 

However, at present, the number of terminals 
supporting IGMPv3 or MLD v 2 is not large. Since the 
cost of IGMPv3 or MLD v2 is higher than that of a 
5 conventional any-source multicast group management 
protocol, these multicast group management protocols 
are estimated that the possibility of actual 
implementation to low cost terminals typified by 
network appliances are also low in future. 

10 Consequently, some techniques for accommodating 
terminals, each of which does not support IGMPv3 or 
ML D v 2 as the s o u r c e - s p e c i f i c multicast group 
management protocol, to a s o u r c e - s p e c i f i c multicast 
network have been proposed. 

15 For example, in IGMPv3 Lite of Cisco Systems, 

Inc., by implementing an IGMPv3 translation library 
having specified function in an application of an end 
user terminal, the end user terminal can join a 
s o u r c e - s p e c i f i c multicast network via the 

20 translation library even when the application of the 
end user terminal does not actually support IGMPv3. 
In URD (URL Rendezvous Discovery) of Cisco Systems, 
Inc. , the end user designates the address of a 
multicast source server to a router with HTTP (Hyper 

25 Text Transfer Protocol) , so that a request to join 
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a s o ur c e - sp e c i f i c multicast network can be notified 
to the router even when the end user terminal and 
application do not support IGMPv3. 

Except for those conventional techniques, by 
5 allowing a router itself to make a line to statically 
join a multicast group including a specified multicast 
source, multicast traffic from the specified source 
can be flowed to the line even when an end user terminal 
on the line does not support IGMPv3 (Cisco Systems, 

10 Inc.: "Source-Specific Multicast with IGMPv3, IGMPv3 
Lite, and URD feature module, Release 12.1(5)T", 
http : //www . cisco . com/univercd/cc/td/doc/product/s 
oftware/iosl21/121newft/121t/121t5/dtssm5t.htm) . 

One of advantages of the s o u r c e - s p e c i f i c 

15 multicast is that by permitting only a multicast 
transmission from a specific source, network 
resources can be prevented from being wasted by 
multicast transmission from an unspecified source. 
As one of proposals for improving the s o u r c e - s p e c i f i c 

20 multicast from such a viewpoint, there is multicast 
routing protocol (draf t-lehtonen-magma-mcop-0 0 . 
txt) proposed by Lehtonen of Sonera Corp. 

In this system, upon receiving a request to join 
s o u r c e - sp e c i f i c multicast, a multicast forwarding 

25 equipment inquires a multicast control server of 
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whether joining is possible or not, so that the 
multicast control server can manage the filtering of 
requests to join the s ou r ce - s pe c i f i c multicast. 

5 SUMMARY OF THE INVENTION 

The conventional techniques for connecting a 
terminal, which is not adapted to s o u r c e - s p e c i f i c 
multicast, to a s o u r c e - s p e c i f i c multicast network 
have the following two problems. 

10 The first problem is that a computer or an 

application on the end user side cannot adapt to the 
source-specificmulticast unless it is modified. The 
above-described IGMPv3 Lite andURD have this drawback 
Specifically, in the case of IGMPv3 Lite, an 

15 application has to be reconstructed by using a 
translation library. In the case of URD, separately 
from the application, the user has to take a procedure 
of joining the s o u r c e - s p e c i f i c multicast network. 
Consequently, it requires much trouble to the user 

20 than joining to an any-source-multicast network. 

In the case where a router itself makes a terminal 
on a specific line statically join to multicast, the 
first problem does not occur. However, in this case, 
even when there is no multicast participant actually, 

25 multicast traffic flows into the specific line 
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statically joined the multicast group by the router. 
Consequently, there is a second problem such as 
occurrence of congestion caused by wasting a bandwidth 
on the specific line and unnecessary line cost to the 
5 user. 

An object of the invention is to solve both of 
the above two problems simultaneously . Specifically, 
an object to be achieved by the invention is to enable 
an end user terminal adapted only to any-source 

10 multicast to dynamically join or leave a source- 
specific multicast network without changing the 
term inal function. 

To achieve the object, according to the invention, 
an any-source multicast group join request sent from 

15 a client node to a router is translated into a source- 
spec i f i c -mu 1 1 i c a s t group join" request. For the 
translation, a multicast source address table is used. 
In the management table, the correspondence relations 
among the router, a multicast group address, a source 

20 node of a multicast group management packet, and a 
multicast packet source server are managed. The 
management table is similar to a management table used 
in multicast control protocol. 

By using the management table, each router to 

25 which end user terminals (client nodes) are connected 
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translates an any-source multicast group join request 
into a request to join a s o u r c e - s p e c i f i c multicast 
group in which the source of a multicast packet is 
limited to a specific server permitted by a network 
administrator. 

Also when the router inquires a line of whether 
a client node joining a s o u r c e - s p e c i f i c multicast 
group exists or not, the router inquires of the 
presence or absence of a client node joining the group 
in an any-source multicast f ormat'af ter searching the 
management table to determine that the client node 
on the line is permitted to join .a multicast group 
in which a multicast source is specified. 

A feature of the invention resides in that packet 
forwarding equipment to which a multicast client node 
is connected performs processing of a request to join 
or leave a multicast g r oup received from the multicast 
client node, which does not have the function of 
designating a multicast source address, after 
translating the request into a request to join or leave 
a s o ur c e - s p e c i f i c multicast group requiring 
designation of a multicast source address. The 
packet forwarding equipment can determine a multicast 
source address to be designated on the basis of an 
address of the multicast client node and an address 
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of the multicast group to which the join or leave 
request has been sent. 

More specifically, the packet forwarding 
equipment according to the invention has a table for 
5 indicating the relation of a multicast group address , 
a mu lticast client node address, and a multicast source 
address. When a request to join or leave a multicast 
group is issued from a multicast client node which 
does not have a function of designating a multicast 

10 source address, the packet forwarding equipment 
searches the table for an entry including the address 
of the multicast client node which has issued the join 
or leave request and the address of the multicast group 
to which the join or leave request has been sent, and 

15 designates a multicast source by using a multicast 
source address indicated in the retrieved entry. 

When the multicast source address of the entry 
retrieved from the table is "don't care", the request 
may be treated as a request to join or leave an 

20 any-source multicast group which does not designate 
a multicast source. The table is installed either 
in the packet forwarding equipment or in a different 
apparatus which can be accessed by the packet 
forwarding equipment via a line. 

25 Another feature of the invention resides in that 



f 
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packet forwarding equipment to which multicast client 
nodes are connected is enabled to detect whether a 
multicast client node joining a s o u r c e - s p e c i f i c 
multicast group requiring designation of a multicast 
5 source exists on a network or not even in the case 
where the multicast client node does not have a 
function of responding to a source-specif ic multicast 
join query. In this configuration, by searching a 
table indicating relations among a multicast group 

10 address, a multicast client node address, and a 
multicast source address, whether or not a multicast 
client node joining a source-specific multicast group 
exists in a network is detected. 

Another feature of the invention resides in that 

15 the packet forwarding equipment to which multicast 
client nodes are connected is provided with a 
management table for managing the correspondence 
relation among a multicast group, an address of a node 
serving as a client of the multicast group, and an 

20 address of a multicast source in the multicast group, 
and an any-source multicast group join request is 
translated into a s o u r c e - s p e c i f i c multicast group 
join request by using the management table. 

Another feature of the invention is a method of 

25 translating an any-source multicast group join 
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request to a s o u r c e - s p e c i f i c multicast group join 
request. More concretely, with reference to a 
multicast source address table on the basis of 
multicast group address included in a multicast group 
5 join request sent from a node, which supports 
any-source multicast only, and a line to which the 
join request is issued, a multicast source server in 
a multicast network permitted by a network 
administrator is specified. 

10 A multicast router translates a request to join 

an any-source multicast group into a request to join 
a multicast group in which a specific source server 
permitted by a network administrator multicasts 
packets. When the multicast router periodically 

15 checks whether a client node joining the multicast 
group specifying the source server exits in a network 
or not, the address of the multicast source server 
in the multicast network permitted by the network 
administrator is retrieved from the multicast source 

20 address table on the basis of the multicast group 
address and the line on which the join request is 
issued . 

When the source server address retrieved from 
the multicast source address table does not match the 
25 address of a specific source server in a multicast 
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group to be checked, the multicast router judges that 
a client node joining the multicast of the source 
server does not exist on the line. 

In the case where the source server address 
5 retrieved from the multicast source address table 
matches the address of a specific source server in 
a multicast group, the mu It i cast router checks whether 
a client node joining the multicast group exists on 
the line or' not without designating a multicast source 

10 server in a manner similar to the conventional 
technique. Depending on whether a node joining the 
multicast group is found or not at this occasion, 
whether a node joining the multicast group in which 
the specific source server multicast packets exists 

15 on the line or not is determined. 

Another feature of the invention resides in a 
request translation method for a network including 
a multicast client, multicast forwarding equipment 
to which the multicast client is connected, and a table 

20 indicative of a relation of a multicast group address , 
an address of the multicast client, and a multicast 
source address, wherein when a request to join the 
multicast group is issued from the multicast client 
without designating multicast source address, the 

25 multicast forwarding equipment retrieves, from the 



multicast source address table, the multicast source 
address corresponding to the address of the multicast 
client indicated in the join request and the multicast 
group address, thereby translating the multicast 
group join request having no designation of the 
multicast source into a multicast group join request 
having designation of the multicast source address. 



Further another feature of the invention resides 



a multicast client, a multicast forwarding equipment 
to which the multicast client is connected, and a table 
indicative of a relation of a multicast group address, 
an address of the multicast client, and a multicast 
source address, wherein when a query to join the 
multicast group specifying multicast source address 
is issued in an interface of the multicast forwarding 
equipment, the multicast source address 

corresponding to the multicast group defined by the 
network administrator is retrieved with reference to 
themulticast source address table based on the address 
of the interface. 

The scope of the invention also includes a network 
system realizing the above described methods and a 
network system to which the above described packet 
forwarding equipment is applied. 




method for a network including 
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BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a block diagram showing a whole image 
of multicast routing to which the invention is applied. 
5 FIG. 2 is a block diagram showing a whole source- 

specific multicast routing translating module to 
which the invention is applied. 

FIG. 3 is a flowchart showing a method of 
translating an a ny - s o u r c e -mu 1 t i c a s t join request 
10 into a join request to a multicast group in which a 
multicast source is limited to a source server 
permitted by a network administrator, executed by an 
input/output interface of a multicast join or leave 
request in a multicast router. 
15 FIG. 4 is a flowchart showing a method of 

translating a'query from a s o u r c e - s p e c i f i c -mu 1 1 i c a s t 
join terminal to a query of an a ny - s o u r c e -mu 1 t i c a s t 
group join terminal, executed by the incoming and 
outgoing interface of a multicast j oin or leave request 
20 in the multicast router. 

FIG. 5 is a block diagram showing a whole system 
as another embodiment of the invention in which the 
input/output interface of a multicast join or leave 
request is placed on the outside of the router. 
25 FIG. 6 is a block diagram showing a whole system 
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as another embodiment of the invention in which a 
multicast source server management table is placed 
on the outside of the router. 

FIG. 7 is a block diagram showing a whole system 
as an embodiment of automatically updating the 
multicast source server management table according 
to a request from the user. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
Embodiments of the invention will be described 
concretely hereinbelow. 

FIG. 1 shows a whole image of s o u r c e - s p e c i f i c 
multicast routing to which the invention is applied. 
FIG. 2 is a block diagram showing a whole 
source-s pe cific multicast routing translating module 
to which the invention is applied. FIG. 3 is a 
flowchart showing a method of translating a request 
to join an an y - s ou r c e -mu 1 t i c a s t group to a request 
to join a source-specific multicast group in which 
a multicast source is limited to a source server 
permitted by a network administrator, executed by an 
edge router in a position at which client nodes are 
connected to a multicast network. FIG. 4 is a 
flowchart showing a method of translating a query of 
a source-specif ic-multi.cast join terminal to a query 



of an any-source-multicast group join terminal . With 
reference to FIGS. 5, 6, and 7 , other embodiments of 
the invention will be introduced. 

First, a method of realizing common multicast 
5 communi cation will be described with reference to FIG. 
1. At the time of joining a multicast group, a 
multicast client node (terminal) 100 transmits a 
request to join a -multicast group to a multicast router 
110 in a position of directly .accommodating the node 

10 100. In the case of conventional any-source- 
multicast, a multicast group management protocol such 
as IGMPv2 or MLDvl is applied. In the case of source- 
specific-multicast, a multicast group management 
protocol such as IGMPv3 or MLD v 2 is applied. 

15 In the multicast router 110, the request to join 

the multicast group is received by a multicast group 
management packet processing module 114 via a line 
116. The multicast group management packet 

processing module 114 notifies a multicast routing 

20 manager 112 of the received multicast join request. 

The multicast routing manager 112 notifies the 
multicast j oin request to a multicast router 121 , which 
exists in the direction toward a packet source in the 
multicast group the multicast client node 100 wishes 

25 to join, among neighboringmulticast routers. In the 
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case of source-specific multicast, the multicast 
router 121 corresponds to a next-hop router to reach 
a preliminarily designated source address by unicast. 
In the case of any-source-multicast, the multicast 
5 router 121 corresponds to a next-hop router used to 
reach an address called a rendezvous point defined 
by the network administrator in correspondence with 
a group address. For notification of a request to 
join (or leave) a multicast group between the routers, 

10 multicast routing protocol such as PIM-SM is used. 

Simultaneously with the notification of the 
multicast join request to the multicast router 121, 
the multicast routing manager 112 adds to a multicast 
packet forwarding module 118 a control parameter 

15 setting for forwarding a packet addressed to the 
multicast group (in the case of the s o u r c e - sp e c i f i c 
multicast, further, a condition that the source of 
the packet being a pre-designated source is checked) 
received fromthe router 121 to the line 116 connected 

20 to the multicast client node 100. 

By repeating the notifying operation and the 
addition of control parameter setting for packet 
forwarding, all of multicast routers located between 
the multicast client node 100 and a source node (or 

25 server) of the multicast packet can know the multicast 
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routing information. 

In the case of the any- s ou r c e-mu 1 t i c a s t , only 
a multicast router existing between the multicast 
client node 100 and a multicast router as a rendezvous 
point knows the multicast routing information. A 
multicast router located between the rendezvous point 
and the multicast packet source node does not always 
know the multicast routing information. However, 
this case is based on the premise that all of routers 
know the location of the rendezvous point and the 
multicast packet from the source node can always reach 
the rendezvous point corresponding to the multicast 
group. Consequently, all of routers between the 
source node and a receiving node can know the mu 1 1 i c a s t 
routing information finally. Accordingly, when a 
multicast source server 130 in a multicast network 
120 communicates with the multicast group, this 
communication reaches the multicast client node 100 
via multicast routers 122, 121 and 110. 

The multicast group management packet 
processing module 114 in the multicast router 110 
periodically inquires the line 116, on which the 
multicast client node 100 exists, of the presence or 
absence of a node which joins the multicast group, 
in order to grasp whether the multicast client node 
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100 is joining the multicast group or not. In the 
case where the multicast client node 100 joins the 
multicast group, the multicast client node 100 sends 
back a request to join the multicast group in response 
to the query'. 

In the case of the source-specific multicast,' 
the protocol used for the above commun i cation is IGMPv3 
or MLDv2 . In the case of the any-source-multicast, 
the protocol is I GMP v2 or MLDvl . After the multicast 
client node 100 leaves the multicast group, nothing 
is sent in response to the query. 

When the multicast join request is not received 
by the line 116 for predetermined time, the multicast 
router 110 judges that a multicast client node joining 
the multicast group does not exist on the line 116, 
and sends a request to leave the multicast group to 
the multicast router 121 neighboring in the direction 
of transmission source of the multicast packet by using 
a multicast routing protocol such as PIM-SM. At this 
time, the multicast routing manager 112 deletes, from 
the multicast packet forwarding module 118, the 
control parameter setting for forwarding a packet (in 
the case of the source-specific multicast, a packet 
sent from a designated source) addressed to the 
multicast group and received from the router 121 to 



a network in which the multicast client node 100 
exists . 

By repeating the operation of notifying of the 
leave request and deletion of parameter setting for 
5 packet forwarding, the lapse of routing information 
for the multicast group in the edge router 110 is 
propagated to all of the multicast routers in the 
network 120. As a result, even if themulticast source 
server 130 sends a packet to the multicast group, the 

10 packet does not reach the multicast client node 100. 

In the any-source-multicast, the join request 
or leave request notified from the multicast client 
node 100 to the whole network 120 via the multicast 
router 110 designates merely the address of the 

15 multicast group as an object of join or leave. 

On the other hand, in the source-specific- 
multicast, the join request sent from the multicast 
client node 100 designates a pair of the address of 
themulticast source server 130 and themulticast group 

20 address. Consequently, in the case of the source- 
spec i f i c -mu 1 1 i c a s t , the routing control in the 
network 120 can be realized so that only traffic from 
the multicast source server 130 designated by the join 
request reaches the multicast client node 100 as a 

25 reques ter . 
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In the case of the any-source-multicast, traffic 
to the designated multicast address sent from a 
multicast source server 131 which is not designated 
by the join request can reach the multicast client 
5 node 100 in a manner similar to traffic from the 
designated multicast source server 130. 

On the other hand, in the source-specif ic- 
multicast, a multicast packet from the multicast 
source server 131 which is not designated by the 

10 multicast client node 10 0 does not reach the multicast 
client node 100 since parameter setting for forwarding 
the multicast packet does not exist in the network 
120. That is, the routing control is performed so 
that when traffic having the same multicast address 

15 is received, if the source server is different from 
the designated source server, the traffic is prevented 
from, reaching the client which has sent the join 
r equ est. 

To realize the source-specific-multicast, in 
20 both of communication between the multicast client 
node 100 and the multicast router 110 and c ommun i ca t i on 
between the multicast router 110 and the neighboring 
multicast router 122 , the pair of the multicast source 
server address and the multicast group address has 
25 to be notified. Between the routers 110 and 122, 
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designation information of the multicast source 
server can be communicated by using, for example, the 
existing multicast control protocol PIM-SM (Protocol 
Independent Multicast Sparse Mode) specified in IETF 
5 RFC 2362 . 

Although the multicast group management 
protocol is used for communication between 'the 
multicast client node 100 and the multicast router 
110, as described in the related art, all of client 

10 nodes do not necessarily support the multicast group 
management protocol capable of designating a 
multicast source server address. Therefore, it is 
an issue to achieve a method of managing the multicast 
group between the multicast client node 100 and the 

15 multicast router 110 in order to realize the 
source-specific-multicast . 

In IGMPv2 or ML D vl applied to the multicast group 
management between the multicast client node 100 and 
the multicast router 110, three kinds of management 

20 packets of a request to join the multicast group 
("Join 7 ') , a query of join ("Query") , and a leave 
request ("Leave") are defined and used in the 
above-described manner. Therefore, when the 

multicast client node 100 does not have the function 

25 of designating the address of the multicast source 
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server, it is sufficient for the multicast router 100 
to translate management packets of the any-source- 
multicast group into management packets for the 
source-specific-multicast with respect to the above 
5 three kinds of management packets. The method of 
translating the three kinds of management packets will 
be described hereinbelow. 

Referring to FIG. 2, a method of translating the 
join request (Join) and the leave request (Leave) for 

10 the any-source-multicast into management packets for 
s ou r c e - s pe c i f i c -mu 1 t i c a s t in accordance with the 
invention will be described. 

Amulticast source address table 220 manages the 
correspondence relations among . multicast group 

15 address 222 , amulticast groupmanagementpacket (Join 
or Leave request) source 223, and a multicast source 
address 22 4. In the embodiment, it is assumed that 
proper parameter setting is preliminarily made in each 
of entries in the multicast source address table 220 

20 by the router administrator. 

Referring to FIG. 3, a method of translating an 
any- sour ce-mul t i ca s t join request received from the 
line 116 into a s o u r c e - s p e c i f i c -mu 1 t i c a s t join 
request carried out by a multicast group management 

25 packet translating module 210 in the multicast router 
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110 will be described. 

When a multicast join request packet is received 
from the multicast client node 100 (step 300) , the 
multicast group management packet translating module 
5 210 determines whether the received request packet 
is the source-specif ic-multicast join request packet 
or the any-source-multicast join r eque st packet (step 
310) . In the case where the received packet is IGMP 
of IPv4 or ML D of IPv6, it is able to discriminate 

10 whether the received packet is of a s our ce- spec i f i c 
type or an any-source type, concretely, on the basis 
of the packet length. 

When the received packet is of the source- 
specific type, the multicast group management packet 

15 translating module 210 transfers the received 
source-specif ic-multicast join request packet as it 
is to the multicast group management packet processing 
module 114 (step 350). 

When the received packet is not of the source- 

20 specific type, the multicast group management packet 
translating module'210 searches the multicast source 
address table 220 for an entry having the multicast 
group management packet source 223 and the multicast 
group address 222 matching the source address (the 

25 address of the multicast client node 100) of the 



multicast join request packet and the multicast group 
address designated in the multicast join request 
packet (step 330 ) . 

When an entry matching the join request does not 
5 exist in the multicast source address table 220, it 
means that the multicast group join request from the 
multicast client node 100 is refused by the network 
admi n istrator , so that the multicast group management 
packet translatingmodule 210 ignores the join request 

10 (step 340) . 

When an entry matching the join request exists 
in the multicast source address table 220, the 
multicast group management packet translating module 
210 checks the contents of the multicast source address 

15 224 of the retrieved entry. If the contents of the 
multicast source address 224 is "don't care", it means 
that the multicast group join request' is to be 
processed as the request of the any-source type. In 
this case, the received packet is transferred as it 

20 is to the multicast groupmanagement packetprocessing 
module 114 (step 360). 

In the case where the contents of the multicast 
source address 224 is other than "don't care", the 
multicast group management packet translating module 

25 210 judges that the received request is the request 
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to join the multicast group requiring the designation 
of a source server (source address) indicated by the 
entry retrieved in step 330, translates the join 
request into a multicast group join request of the 
5 source-specific type (step 365) , and transfers the 
resultant request to the multicast group management 
packet processing module 114 (step 3 7 0 ) . The 
multicast group management packet processing module 
114 in the multicast router 110 translates the 

10 multicast leave request of the any-source type 
received from the line 116 into a leave request of 
the source-specific type by the same method as the 
■ above described flowchart. 

With reference to FIG. 4, a method of translati n g 

15 a source-specific multicast join query (Query) issued 
by the mu lticast routingmanager 112 into an any-source 
mu lticast j oin query carried out by the multicast group 
management packet translating module 210 in the 
multicast router 110 will be described. 

20 When a multicast join query packet to be sent 

to the line 116 is received from the multicast routing 
manager 112 via the multicast group management packet 
processing module 114 (step 400) , the multicast group 
management packet translating module 210 determines 

25 whether the received query packet is a source-specific 
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type multicast join query or an any-source type 
multicast join query (step 410) . 

If the received query packet is of the any-source 
type, the multicast group management packet 
5 translating module 210 transfers the multicast join 
query packet as it is to the designated line 116 (step 
420). If the received query packet is, of the 
s ou r c e - s pe c i f i c type, the multicast source address 
table 220 is searched for an entry having the multicast 
10 group address 222 and the multicast group management 
packet source 223 matching the multicast group address 
included in the query packet and the address of the 
line 116 to which the query packet is to be sent (step 
430) . 

15 When an entry matching the query packet does not 

exist in the multicast source address table 22 0, it 
means that operation of the multicast group is refused 
by the network administrator. In this case, the 
multicast group management packet translating module 

20 210 does not transmit the join query packet to the 
line 116 (step 440) . 

When an entry matching the query packet exists 
in the multicast source address table 220, the 
multicast group management packet translating module 

25 210 checks whether the address indicated by the 
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multicast source address 224 of the entry includes 
the multicast source address indicated in the 
source-specific type multicast join query packet or 
not ( step 4 5 0). 
5 If the multicast source address is not included 

in the address of the multicast source address 224, 
it means that the request to join the multicast is 
r e f u s ed by t h e n e two r k admi n i s t r a t o r . Therefore, the 
multicast group management packet trans la ting modul e 

10 210 does not transmit the join query packet to the 
line 116 (step 440) . 

If the multicast source address is included in 
the address- of the multicast source address 224, it 
means that the multicast source address is permitted 

15 by the network administrator. Therefore, the 

multicast group management packet translating module 
210 translates the source-specific multicast join 
query packet into an any-source multicast join query 
packet having the multicast group address (step 455) 

20 and transmits the resultant packet to the line 116 
(step 460) . 

As described above, in the invention, since the 
multicast group management packet processing module 
114 of the multicast router 110 translates the 
25 any-source multicast group management packet to the 



29 

source-specific multicast group management packet, 
it appears for the multicast routing manager 112 of 
the multicast router 110 that a client node supporting 
the source-specific mu lticast exists on the line 116. 
5 According to the invention, therefore, it is 

unnecessary to change the routing control between the 
multicast router 110 and the neighboring multicast 
router 122. In the multicast network 120, an element 
to be changed in order to realize the invention is 

10 only the multicast router 110 to which the multicast 
client node 100 is connected. 

In the invention, since a client node does not 
support the source- specific multicast group 
management protocol, the user cannot choose an 

15 arbitrary multicast source server. With respect to 
this point, the translating technique does not 
perfectly translate an any-source multicast node to 
a s o u r c e - sp e c i f i c multicast node. However, as 
described in the related art, the source-specific 

20 multicast is directed to multicast communication from 
a small number of servers such as a streaming server, 
and the streaming server is operated generally by a 
network administrator. Consequently, even if the 
user cannot freely choose the multicast source server, 

25 a problem hardly occurs in actual operation. 
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Referring now to FIGS. 5, 6, and 7, other 
embodiments of the invention will be described. 

In the embodiment of FIG. 2, the function, of the 
multicast group management packet translating module 
5 210 is installed in the multicast router 110. 

FIG. 5 shows an embodiment in which the function 
of the multicast group management packet translating 
module 210 is provided on the outside of the multicast 
router 110, specifically, in a multicast group 
10 management packet translation equipment 500 disposed 
between the multicast client node 100 and the multicast 
router 110. In this case, the multicast group 
management packet translation equipment 500 passes 
received packets other than the multicast group 
15 management packet so as to be communicated between 
the multicast client node 100 and the multicast router 
110 . 

When a multicast management packet is received 
from a line 501 (or 50 2 ) , the multicast group 

20 management packet translating module 210 translates 
the received packet according to processes described 
below, and output the resultant packet to the line 
5 0 2 (or 501) . Specifically, the multicast group 
management packet translating module 210 functions 

25 as protocol translation equipment for translating an 
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any-source type multicast join request packet and a 
leave request packet received from the multicast 
client node 100 into request packets adapted to 
source-specific multicast accordi n.g to the procedure 
5 of FIG. 3, transferring the resultant packets to the 
multicast router 110, translating s o u r c e - s p e c i f i c 
type multicast join or leave query packets input from 
the multicast router 110 into query packets adapted 
to any-source multicast according to the procedure 

10 of FIG. 4, and transferring the resultant packets to 
the multicast client node 100. 

The embodiments of FIGS. 2 and 5 are based on 
the premise that the multicast group management packet 
translating module 210 has the multicast source 

15 address table 220. FIG. 6 shows an embodiment in 
which the multicast source address table 220 is 
provided apart from the multicast group management 
packet translating module 210. 

When the searching process of the multicast 

20 source address table 2 2 0 is carried out by the 
processing routines of FIGS. 3 and 4, in the 
embodiments of FIGS. 2 and 5, the internal table 220 
is referred to. In the embodiment of FIG. 6, the 
multicast router 110 sends a query to a multicast 

25 source address management server 600 having the 
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multicast source address table 220 via a network, 
thereby to perform a search similar to the above. 

According to this embodiment, the multicast 
source address table required by the multicast routers 
5 can be managed in a centralizedmanner by the multicast 
source address management server 600. In this case, 
each multicast router searches an entry from the 
multicast source address table 22 0 by sending a query 
to the management server 600. It is sufficient to 

10 use, as a communication protocol applied to a query 
to the management server 600, an existing network 
database search protocol such as "Radius" (RFC2 8 65 ) . 

FIG. 7 is a diagram showing a whole system of 
an embodiment of automatically updating the multicast 

15 source address table 220 according to a request from 
the user. In the embodiments of FIGS. 2, 5, and 

6, it is assumed that entries of the multicast source 
address table 220 are set by the network a dm in i s t r a t o r . 
By realizing the invention with the system 

20 configuration of FIG. 7, setting of entry data into 
the multicast source address table 220 can be 
semi-automated . 

Generally, in the case of multicasting onerous 
contents, for example, subscription of onerous 

25 contents has to be managed for each user by a contract 
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management server 700. In a contract management 
table 720 managed by the contract management server 
700, a correspondence relation between user network 
information 711 and a subscribed session (combination 
5 of a source server and a multicast group address) 712 
is registered. 

By reflecting the contents of the contract 
management table 720 to the multicast source address 
management server 600 via a network, the contents of 

10 the multicast source address table 220 can be 
automatically updated or deleted according to a 
request from the user. As a communication protocol 
used between the contrast management server 700 and 
the multicast source address management server 600, 

15 for example, an existing communication protocol such 
as HTTPS having a security function for preventing 
the multicast source address table 220 from being 
illegally updated can be applied. 

According to the invention, only by changing the 

20 function of a multicast router to which the end user 
terminal is directly connected, the end user terminal 
supporting only any-source multicast can join a 
source-specific multicast network . According to the 
invention, since a multicast router determines 

25 whether the end user joins or leaves multicast group, 
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on the basis of a multicast network join or leave 
request from the end user terminal, it is able to stop 
the supply of the multicast traffic to the end user 
at the time when the end user does not need multicast 
traffic . 



